ASIC design technique

ABSTRACT

A view-based design technique for an ASIC includes selecting a particular multiple level hierarchy and for each level in the hierarchy creating a hardware description language file which declares the relevant signals and module instantiations.

FIELD OF THE INVENTION

[0001] The present invention relates to the design of applicationspecific integrated circuits. More particularly it relates to a designtechnique which is intended to be particularly suitable for applicationspecific integrated circuits (ASICs) which are mainly composed of aselectable multiplicity of functional blocks or ‘cores’ and the circuitis designed to conform to various architectural rules which prescribethe manner in which signals pass between the cores by way of memorybuses, for data signals, register buses, for signals employed to read orwrite from control or status registers in cores, and control buses, forsignals such as interrupts for processors. Thus it is particularlyrelevant to ‘system on a chip’ design wherein a plurality of distincthardware cores are integrated together in order to create a much largerdesign. The invention is generally applicable to ASIC design employing ahardware description language (HDL).

BACKGROUND OF THE INVENTION

[0002] It is now commonplace to employ what is known as ‘top-downdesign’ otherwise termed functional decomposition, for the design ofapplication specific integrated circuits. In this process, the ASIC isdecomposed into several top level functions. Each block has its signalinterfaces defined and its functions clearly stated. This top-downtechnique is applied recursively down through the design, breaking upeach new top-level module into a set of sub-modules until the functionof the sub-module is such that it can be readily described in terms ofhardware and designed as a single state machine or equivalent.

[0003] During the decomposition, modules are partitioned by function. Itis much easier to design a module with a unified function rather than asa group of miscellaneous functions. Top-down design is complete once thesub-modules do not logically divide down any further, they implement awell defined function or set of functions and are of a manageable designsize.

[0004] In an ASIC design described by a hardware description language(HDL), such as Verilog and VHDL, the functionality of a module isdefined by a combination of structural connections between blocks(module instances) and algorithmic logic. At higher levels offunctionality, the design consists of structural, rather thanalgorithmic, HDL.

[0005] Development activity focuses on the lowest level sub-modules asdefined by the top-down design process. These modules, known hereafteras cores, are functionally non-trivial and usually consist of a mixtureof structural and algorithmic Verilog. Typically they are the subject ofseparate, individual design and may be held in a ‘library’ to which theASIC designer has access. The intermediate modules that were definedduring top-down design contain only hierarchical or structural HDL. Thehierarchical HDL describes the interconnections between cores and at thetop level the chip's input and output pins. It does not contain anyalgorithmic logic.

[0006] The structural HDL describing the design hierarchy is usuallygenerated by hand. Any changes to the core interfaces or to thehierarchy are therefore time-consuming, onerous and prone to error. Atany level within the hierarchy it is likely that the designer will haveto deal with large numbers (tens or even hundreds) of signals. Theadvent of large SoC designs made up of many millions of gates andcontinuously shrinking IC geometries means that the size of thehierarchical HDL will continue to increase. It is a difficult task toensure that the connections between the cores are correctly maintained.It is difficult to maintain a consistent signal naming convention assignals descend and ascend through the hierarchy. This is made even moredifficult if many different designers are (as is commonplace) working oncreating or modifying the hierarchical HDL. An inconsistent namingconvention can result in confusion and lost time during system-levelsimulation and debugging.

SUMMARY OF THE INVENTION

[0007] The present invention concerns a view-based technique whichfacilitates the creation of a self-consistent description of a complexdesign in a hardware description language. The technique allows amultiplicity of different hierarchical views to suit different aspectsof the design which is to be created. Typical views include a layoutview, a subsystem simulation view, a view to match EDA tool requirementsand a functional decomposition view. The HDL hierarchy of each of theseviews can be optimised to best meet the requirements of the particulartask under-completion. The number of levels in the HDL hierarchy can beradically different depending on the task. The starting point for thecreation of the new hierarchical views would be an existing hierarchydefined using top-down design techniques.

[0008] Formal verification techniques allow engineers to comparedifferent netlists to prove that they are functionally equivalent. Anetlist is converted into mathematical models that represent the HDLdescriptions. When formal verification techniques are applied todifferent HDL hierarchies with the same cores and the same interfaceconnections then they will be proved to be functionally equivalent.

[0009] The nature of the invention and further features of it will bemade clear in the following description with reference to theaccompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

[0010]FIG. 1 illustrates a plurality of cores, namely functional blocks,in a deliberately simplified application specific integrated circuit.

[0011]FIG. 2 is a diagram illustrating two different hierarchies.

[0012]FIG. 3 illustrates an ASIC and its connections to externaldevices.

[0013]FIG. 4 illustrates one example of a hierarchy employed using atop-down design approach.

[0014]FIG. 5 is a diagram illustrating a hierarchy based on clockdomains.

[0015]FIG. 6 illustrates two different hierarchical groupings for thesame set of modules in an ASIC.

[0016]FIG. 7 is a diagram illustrating the interconnection of cores bymemory paths.

[0017]FIG. 8 is a diagram illustrating the interconnection of cores byregister bus paths.

[0018]FIG. 9 is a diagram illustrating the interconnections of cores bycontrol paths.

[0019]FIG. 10 is a UML model of connections representation ofconnections captured using a schematic entry tool.

[0020]FIG. 11 illustrates the sub-classification of ports.

[0021]FIG. 12 is a UML model of a hierarchy and connections.

DETAILED DESCRIPTION

[0022] 1. Background

[0023] Although the invention is intended to have more general utility,it is intended in one form to facilitate the design process of systemson a chip which are designed and organised according to the techniquesdescribed in the following co-pending applications, which are commonlyassigned herewith, incorporated by reference herein, and brieflysummarised below.

[0024] (a) Ser. No. 09/893,659 filed Jun. 29, 2001 for Creedon et al.describes an architecture in which the functional blocks or coresexchange data messages substantially only by way of memory, the coresbeing able to initiate memory transactions (reads and writes) on amemory bus system which includes aggregators that can arbitrate betweenmemory transactions proceeding from different cores to the same commonmemory (which may be on-chip or off-chip) and which allows differentdata rates and bus widths on different sections of the memory bussystem.

[0025] (b) Ser. No. 09/919,806 filed Aug. 2, 2001 for Boylan et al.describes the automatic generation in a hardware description language ofthe interconnects required according to the predetermined architecture.These interconnects include the memory bus system, a register bus systemby means of which cores and particularly processors, can monitor orcontrol registers within other cores, and control buses, for theconveyance of such signals as interrupts.

[0026] (c) Ser. No. 09/893,658 filed Jun. 29, 2001 for Hughes et al.describes a technique in which memory transactions include a sourceidentification (source ID) and preferably also a transaction number.That technique is intended to avoid ‘freezing’ of paths to memory whilea particularly transaction is being enacted and facilitates an orderlyresponse to memory transactions despite variable latency in the memorybus system.

[0027] (d) Ser. No. 09/879,065 filed Jun. 13, 2001 for Pratt et al.describes a number-based ASIC clock system which constrains clocksderived from a system clock to have transitions at particular times. Thepurpose is partly to avoid the distribution of the system clock as suchthroughout all the ASIC, and thereby to avoid frequency shift owing toexcessive loading of the system clock. It also facilitates inappropriate circumstances the avoidance of ‘elastic’ buffers for thetransfer of signals between cores that may operate at differentsub-multiples of the system clock.

[0028] Some Figures taken from the aforementioned co-pendingapplications are reproduced herein by way of example and explanation.However, the present invention is not intended to be limitedspecifically to the design techniques and architecture indicated in theaforementioned co-pending applications.

[0029] 2. Simple Connections between HDL modules

[0030]FIG. 1 shows by way of example the connections between a number ofdifferent cores denoted ‘core 1’ to ‘core 12’ in an ASIC. In practicethe number of cores and the number of connections would be much largerin a real ASIC. The dashed rectangle R shows one of the levels ofhierarchy (W) introduced into the design in FIG. 2. The dots 1 to 6denote the connections (input and output signals) that constitutes thishierarchical module's interface. Each of the cores represents an HDLmodule that implements a well defined function.

[0031] 3. Hierarchical Views

[0032]FIG. 2 shows two different hierarchies for the cores shown in FIG.1, viz. a flat hierarchy 20 and a system test hierarchy 21 The flathierarchy has one hierarchical HDL module called “Hierarchy.v” whichcontains the twelve core module instantiations and declarations for theconnections between them. The system test hierarchy has fivehierarchical HDL modules (Top_Hierarchy.v, Z_Hierarchy.v, W_Hierarchy.v,X_Hierarchy.v, Y_Hierarchy.v). The module instantiations for the twelvecores are dispersed among the five hierarchical HDL modules, as are theconnections. For example the connection between core11 and core12results in a signal ascending through the following levels in thehierarchy.

Y_Hierarchy→Z_Hierarchy→Top_Hierarchy

[0033] The connection between core3 and core10 results in a signalascending and then descending through the following levels in thehierarchy.

X_Hierarchy→Z_Hierarchy→W_Hierarchy

[0034] Even though the HDL is different the two separate hierarchicalviews would be proved to be functionally equivalent if formalverification techniques were applied.

[0035] The ability to automatically generate different hierarchicalviews depending on the ASIC design task would be of significant benefitto the ASIC design flow. The benefits provided may be illustrated usinga hypothetical design example.

[0036]FIG. 3 illustrates by way of example an ASIC 30 which is requiredto have external interfaces to a microprocessor 31, two Ethernetphysical layers 32, 33 (PHYs), an external memory 34 and a PCI bus 35.Broadly speaking, a schematic diagram such as shown in FIG. 3, butnormally a more complex diagram, would be included within the ‘inputs’or design requirements to a top-down design session.

[0037]FIG. 4 illustrates a hierarchy that arises when employing atop-down design approach for the ASIC shown in FIG. 3. Very typicallythe ASIC includes internal operational blocks such as two Ethernet MACs41 and 42, a serial management interface 43, a CPU interface 44, a PCIinterface 45, a memory arbiter 46 and a host buffer management block 47.The CPU interface decomposes into an interrupt block, a register blockand a protocol interface. The arbiter 46 for the external memorydecomposes into an SRAM interface 48 and an arbiter block 49. Each mediaaccess control MAC may be decomposed into a TX (transmit) host bufferinterface 50, a RX host buffer interface 51, a statistics block 52, anRX (receive) MAC 53 and a TX MAC 54. The RX MAC 53 further decomposesinto a RX flow control block 55, an RX PHY interface 56 and an RXstatistics machine 57. The TX MAC decomposes into a TX flow controlblock 58, a TX PHY interface 59 and a TX statistics machine 60. It isassumed in this description that the reader is familiar with the OSIModel. The term ‘MAC’ is intended to correspond to the data link layerin that model.

[0038] For convenience, the interconnect signals between the variousoperational blocks have been omitted from FIG. 4.

[0039] 4. Grouping for Layout

[0040] The latest deep submicron technologies mean that routing delaysbetween modules now normally dominate over actual individual gate delayswhen laying out SoC chips. In the case of the hypothetical design thefollowing routing layout constraints and solutions might exist.

[0041] (a) The blocks “RX Phy Interface” 56 and “TX Phy Interface” 57may have very tight timing constraints and would need to be placed veryclose to the Ethernet Phy pins.

[0042] Even though these files are buried two levels down in theoriginal hierarchy they should be grouped at the top level in a layouthierarchy in order to identify to the layout tool that they need to beplaced beside each other for layout purposes.

[0043] (b) The “SRAM Interface” 48 has tight timing constraints and mustbe placed near the I/O pins of the memory.

[0044] The “SRAM Interface” could be moved to the top level in thehierarchy and placed beside the memory pins for layout purposes. The“Arbiter” 49 may well not have any tight timing constraints with the“SRAM Interface” and so it could remain at its current level in thehierarchy but should be grouped close to the “Host Buffer ManagementInterface” 47.

[0045] One of the most difficult tasks for the project manager on a ASICproject is to estimate accurately the time it will take to layout achip. Layout is an iterative process wherein the layout results arecommunicated back to the design team. The iterations will stop only whenall timing issues have been resolved. This is often described as “timingclosure”. An ability to modify the hierarchy easily within a netlist cangreatly reduce the time needed to achieve closure.

[0046] 5. Grouping according to Clock Frequency

[0047] When dealing with multiple clock domains on a chip the advicethat is often given is to limit the number of different clock domains inthe chip. Multiple clock domains can often complicate synthesis and scanchain testing. When multiple clock domains are used it is very likelythat meta-stability problems will be encountered if special care is nottaken for signals crossing clock boundaries. SoC type developments havemultiple different IP Cores all running at different clock frequenciesand it is almost impossible to avoid multiple clock domains.

[0048] One of the chief techniques currently employed is to isolate allsignals crossing from one clock domain to another using specialdedicated blocks. These blocks can be synthesised separately and havespecial attention given to them. The synthesis techniques for managingboundary crossing signals can be concentrated on these blocks.

[0049] A more adaptable approach is to group modules according to clockfrequency. The hierarchy introduced by these groupings makes it obviousto designers where special techniques to manage signals crossing clockboundaries need to be applied. This approach has the advantage thatthere is no need for modules dedicated to clock domain crossing withinthe design. Likewise there is no need for exhaustive searches throughoutthe netlist to identify all the signals crossing clock domains; they areimmediately obvious from the hierarchy.

[0050]FIG. 5 illustrates for the ASIC in FIG. 3 five clock domains thatmight exist in the hypothetical design. These domains are represented bythe CPU clock, the PCI clock, a system clock, an Ethernet RX1 clock andan Ethernet RX2 clock.

[0051] It is clear from FIG. 5 that the CPU interface is split acrosstwo clock boundaries, i.e. the system clock and the CPU clock. Forexample, the interface may include a register block which runs at CPUclock, a CPU Protocol block which also runs at CPU clock and aninterrupt controller which runs at the System Clock

[0052] The hierarchical groupings and hence the HDL would be modified sothat the Register block and CPU Protocol block would be contained intheir own level of hierarchy. The interrupt controller would be movedinto a level of hierarchy containing all the modules running at theSystem clock frequency.

[0053] Grouping according to clock frequency can also help in the layoutstage because each clock domain may be restrained in area to limit thedifficulty in balancing a clock tree by wiring and to avoid unnecessaryinterconnect delays on the clocks.

[0054] 6. Grouping for Subsystem Simulation

[0055] Verification of an ASIC consumes at present generally about 70 %of ASIC development effort. The consequences of an inadequateverification process can range from a non-functional design requiringseveral expensive revisions, a design with only a subset of the desiredfunctionality or a delayed product shipment.

[0056] One of the main elements of current verification processes issubsystem simulation. The goal of subsystem simulation is to run testson a number of modules that combine together logically to form a singlehigher level function and that are more efficiently tested as a combinedunit, instead of as individual modules. Subsystem simulation enablessimulation to start earlier in a project; it requires less code thanchip simulation and hence runs more quickly. Furthermore it allows abottom-up verification process, testing the lower levels first and thenbuilding on from there by including other new interconnect blocks orsubsystems. Modules are difficult to test at chip level where inputs tothe modules are difficult to control.

[0057] For these reasons it is very important that a hierarchy thatmatches the requirements of subsystem simulation can be easily created.In the hypothetical design example under discussion there would be threedifferent subsystem simulations that the design team might wish to run,as shown in Table 1: TABLE 1 Subsystem Required Blocks MAC test MAC #1,Host buffer management, External memory arbiter, Register block PCI testPCI interface, Host buffer management, External memory arbiter, Registerblock CPU test PCI interface, Host buffer management, External memoryarbiter, Register block, Serial Management interface

[0058] The facility to create a new HDL hierarchy to match the needs ofa particular subsystem simulation has many advantages. When building thesubsystem simulation environment it is much easier to disable unusedfunctionality. Such unused interfaces would be exposed at the top levelof the new hierarchy and can therefore be easily ‘tied off’. Newsubsystem simulation environments do not need to be created by hand.There is no time lost debugging the manually-created subsystemenvironment and removing errors in the new hierarchy. The verificationeffort can immediately be concentrated on finding and removing realfunctional errors. The fact that the HDL hierarchies are automaticallycreated allows all the various designers to run simulation from the samefunctional base.

[0059] The automatic generation of the subsystem simulation hierarchiesgreatly facilitates the replacement of a core module with any of thefollowing:

[0060] (i) a Structural RTL, represented by actual physical gatestructures (Flops, NAND, Nor gates etc).

[0061] (ii) a C module, i.e. a ‘C’ model performing the functions of thecore.

[0062] (iii) a Transactor, i.e. a higher level behavioural model of theblock, sometimes using structures that cannot be synthesised. Atransactor may be written in HDL or some other higher level language.

[0063] (iv) a Verilog RTL model, i.e. the HDL code used to capture thedesign, being the code that is synthesised to produce the structuralRTL.

[0064] (v) an ‘empty’ module, declaring the necessary input/output pinsbut not containing any logic (and therefore not consuming simulationtime).

[0065] Thus one may create a hierarchical view with differentrepresentations of the core modules. This might be necessary because atthe particular phase of the project, design of all the modules might nothave been completed. The full source code for a particular block mightnot be available or might take too long to simulate (E.g. CPU block).

[0066] In the hypothetical design example the following might bedesirable:

[0067] (i) replacement of the complete RX MAC with a transactor;

[0068] (ii) replacement of the CPU Protocol interface with a ‘C’ model.

[0069] 7. Grouping to match EDA tool requirements

[0070] There is a large selection of Electronic Design Automation (EDA)tools available for use throughout ASIC design. Some of these toolsplace special requirements on the RTL that can affect the HDL hierarchy.Many of the tools used by ASIC vendors require hard core placement ofspecific hard macro types such as CPU blocks, FIFOs, SILOs, PLL's, delaycells, register blocks. A particular vendor's tool set might requirethat a subset of these hard macros be placed at the top level of thehierarchy. If a design is transferred from one vendor to another theblocks required at the top level may change. This could require largemodifications to the netlist and therefore introduce a considerable riskfactor into the design.

[0071] For very large ASIC's a sub-chip design approach is often takenin order to meet the requirements of floor planning and layout tools.The concept behind sub-chip design involves carefully defining theboundary between the notional chips. Because the sub-chips are smallerit is much easier for them to individually meet the layout and floorplanning constraints. The interface between the sub-chips is optimisedin order to meet timing constraints. The ability to explore differentHDL hierarchies would allow this interface to be rapidly defined.

[0072]FIG. 6 shows by way of example two different hierarchicalgroupings A and B for a set of four modules core 1 to core 4. Ingrouping A core 1 and core 3 are grouped together, as are core 2 andcore 4. In grouping B core I and core 2 are grouped together as are core3 and core 4. It is obvious that grouping B has many fewer interfacesignals between groups than does grouping B.

[0073] 8. Hierarchical HDL

[0074] Only a specific subset of the HDL language should be used in thehierarchical HDL (e.g. verilog) in order to ensure that the hierarchycan be modified to suit the different aspects of ASIC design describedpreviously. This subset would consist only of those languauge elementsrequired to define modules and to connect module instances. The RegisterTransfer Level (RTL) subset of both Verilog and VHDL is the subset ofthe language that should be used in creating a design that can besynthesised into actual physical gates; therefore hardware engineers arewell used to using a subset of the language.

[0075] The following defines the subset of HDL that should be used. Forthe purposes of explanation all examples have been given in Verilog buta similar subset can be defined for other HDL languages such as VHDL.Interface Declaration Define the interface of this hierarchical modulemodule myHierarchy ( clk, wrAckReq, HRDATA, HREADY); . . . endModuleInput Signals Declare all input signals input [5:0] signal1; wire [5:0]signal1; Output Signals Declare all output signals output [5:0] signal2;wire [5:0] signal2; Local Signals These are used to define any localconnections between two or more module instantiations at this level inthe HDL hierarchy wire localSignal; Module Instantiations This is usedto create another level of hierarchy below the current level or else tocreate an instance of a core (algorithmic) module moduleFoo myFoo (.reset (hReset), .burstStartEn (1 ′ b1), .clk (clk), .rdAdd (rdAdd[31:0] ) );

[0076] 9. Generation of HDL Hierarchy

[0077] There now follows a top-level description of a possible schemethat could be used to implement a tool to automate the generation ofdifferent hierarchies. The main steps involved in creating a newhierarchical view are as follows:

[0078] (i) Describe the connections (graphically or otherwise) betweenthe cores and model these connections in software;

[0079] (ii) Describe the selected hierarchy (graphically or otherwise)and model this hierarchy in software;

[0080] (iii) For each level in the hierarchy create a hierarchicalverilog file and declare all necessary input/output signals, all localsignals and module instantiations.

[0081] These steps are more particularly described below.

[0082] 10. Describe Connections

[0083] This could be achieved using a spreadsheet or as preferred agraphical picture showing the cores/modules and how they are connectedtogether. FIG. 7, FIG. 8 and FIG. 9, which correspond to FIGS. 1 to 3 ofthe aforementioned application No. 0118840.8, show various cores and,respectively, memory bus connections, register bus connections andcontrol bus connections. As the connections are specified using theschematic entry tool a software model describing the connections will becreated.

[0084]FIG. 10 represents a possible Unified Modelling Language (UML)representation of the connections captured using a schematic entry tool.

[0085] The class ‘Module Instance’ models a HDL module instantiation andits main attribute is the instantiation name of the module. It containsone or more ports which model the module's interface.

[0086] A ‘port’ is used to represent the HDL input and output signalsfrom the module. A port may represent either an individual HDL signal ora collection of signals. A port that contains a collection of signalsmodels a bus such as the mBus and rbus described in the aforementionedapplications or some other bus specification. It might be desirable torestrict the types of ports that can be connected together and also howports can be connected. This would be achieved by sub-classing ports asshown in FIG. 11.

[0087] The model in FIG. 10 shows that a ‘connector’ is used to connecttwo ports. The normal rules of schematic entry would apply to the typeof connections that could be made. A port may have zero or moreconnectors attached to it. This represents the fact that in HDL, signalscan be either left floating or connected to multiple destinations

[0088] A ‘port’ supports multiple ‘connectors’ because a bus such as themBus can be multicast to multiple destinations. Also an individualsignal which is N bits wide can be split so that the discrete segmentsof bits can be connected to different destinations.

[0089] A special type of port or connector would be provided torepresent the case where the signal/signals on a port are being tiedoff. The connector is responsible for ensuring that the signal namingconnection used to map signals to each other as they ascend and descendthrough the HDL hierarchy is consistent.

[0090] The signal class represents a HDL signal which has three mainproperties: width, direction and name.

[0091] 11. Describe Hierarchy

[0092] Before any hierarchical HDL can be generated, the HDL hierarchyneeds to be described. Again, this can be achieved using a spreadsheetor, as preferred, a graphical picture to describe the hierarchy,similiar to that shown previously in FIG. 2. As the user moves modulesfrom folder to folder to create the desired hierarchy the software modelrepresenting it would be modified to reflect the current hierarchy.

[0093]FIG. 12 is an UML diagram which describes how the hierarchy wouldbe represented. Each time the hierarchy is modified a copy of thecurrent hierarchy is made. The model is then modified to reflect thechanges to the hierarchy that have been made graphically. This involvescycling through the tree of hierarchical modules to do the following:

[0094] (a) Deletion of hierarchical modules that no longer exist.

[0095] (b) Creation of new hierarchical modules and insertion of theminto the hierarchy tree.

[0096] (c) Creation of the ports and connectors that constitute the newModule Instances.

[0097] (d) Modification of the set of module instances maintained by ahierarchical module.

[0098] 12. Generate Hierarchical HDL

[0099] Once the user is satisfied with a hierarchy that meets therequirements of 30 the design task (as described earlier) the HDL can begenerated. The following pseudo-code describes the steps involved:ROOT_MODULE = an object that represents the top-level module in thehierarchy. HDL_WRITER = an object that outputs HDL (verilog/VHDL) tofile using the correct syntax. generaterHDLForChildren (ROOT_MODULE,HDL_WRITER) ; generateHDLForChildren ( module , HDLWriter ) {module.getChildren ( ) .iterate ( if ( child.isInstanceOf (“Hierarchical Module ” ) ) generateHDLForChildren ( child , HDLWriter )) ; generateHierarchicalHDL ( module , HDLWriter ) ; }generateHierarchicalHDL ( module , HDLWriter ) { thisModuleInstance =module.asInstance ( ) ; startModuleDeclaration (module) ;thisModuleInstance.getPorts. ( ) .iterat e ( ) { port.getSignals ( ).iterate ( HDLWriter.addSignalToModuleDeclaratio n (signal) ; ) ; }HDLWriter.declareModule ( ) ; moudle.getChildren ( ) .iterate ( ) {child.getPorts ( ) .iterate ( ) { port.getConnector ( ) .iterate ( ) { )if (connector.isConnectedTo ( thisModuleInstance) == FALSE) {HDLWriter.declareLocalSignals (port.getSi gnals ( ) , connector) ; } } }} module.getChildren ( ) .iterate ( ) { startModuleInstantiation (child); child.getPorts ( ) .iterate ( ) { port.getSignals ( ) .iterate ( ) {HDLWriter.addSignalsToModul eInstantiation (signal, port.getConncectors( ) ) ; } } HDLWriter.declareModuleInstantiation ( ) ; }HDLWriter.endModuleDeclaration ( ) ; }

[0100] The following is a description of the functionality provided byeach of the methods in the HDL writer class. The HDL writer class couldimplement the state pattern to ensure that the HDL is output in thecorrect order.

[0101] startModuleDeclaration(Module)

[0102] This method tells the HDL writer that a new Hierarchical moduleis being created. It will create the output file the HDL will be writtento and start the declaration of the module using the module's name.

[0103] addSignalToModuleDeclaration(Signal)

[0104] Adds this signal to the set of signals that make up the module'sinterface.

[0105] declareModule( )

[0106] This method outputs all the signals that make up the module'sinterface from the set of signals created using theaddSignalToModuleDeclaration. It creates the HDL declaration of each ofthe input and output signals. It knows how to query the signal class inorder to extract the necessary information.

[0107] declareLocalSignals({Signal}, Connector)

[0108] This method takes a set of one or more signals and the connectorassociated with them. The method knows how to construct a local signalname based on the attributes of the Signal and connector objects. Itwill declare a local signal for each of the signals in the set.

[0109] startModuleInstantiation(Moduleinstance)

[0110] This method is used to start the instantiation of a module. It isable to extract the instance and module name needed for theinstantiation.

[0111] addSignalsToModuleInstantiation(Signal, {connectors})

[0112] Add this signal to the list of signals that make up the moduleinstantiation. The method knows how to output the mapping between theinternal signal name of the module that is being instantiated and thewire(s) that it is being connected to. The method also handles floatingand tied off signals.

[0113] declareModuleInstantiation( )

[0114] This method outputs the HDL needed to instantiate a module.

[0115] endModuleDeclaration( )

[0116] This method tells the HDL writer that the HDL for thehierarchical module is complete and that the output file can be closed.

1. A method of generating a description in a hardware descriptionlanguage of an application specific integrated circuit composed offunctional cores and interconnections for signals therebetween,comprising the steps of: (i) describing said connections and modellingthem in software; (ii) describing a selected multiple-level hierarchy ofthe cores and modelling the selected hierarchy in software; and (iii)for each level in the selected multiple-level hierarchy, creating ahardware description language file which declares the signals andrelevant module instantiations.
 2. A method according to claim 1 whereinsaid step (i) comprises forming a graphical picture of said functionalcores and interconnections and creating a software model thereof using aschematic entry tool.
 3. A method according to claim 2 wherein saidsoftware model includes instances of modules and ports that representinput and output signals for each module.
 4. A method according to claim1 wherein said step (ii) comprises producing a graphical picture of theASIC in terms of the selected hierarchy.
 5. A method according to claim1 wherein the selected hierarchy is a system test hierarchy.
 6. A methodaccording to claim 1 wherein the selected hierarchy is based on physicalgrouping of cores.
 7. A method according to claim 1 wherein the selectedhierarchy is based on clock domains.
 8. A method according to claim 1wherein the selected hierarchy is based on a grouping for subsystemsimulators.
 9. A method according to claim 1 wherein the selectedhierarchy is based on the requirements of an automatic placement tool.10. A method of generating a description in a hardware descriptionlanguage of an application specific integrated circuit composed offunctional cores and interconnections for signals therebetween,comprising the steps of: (a) describing said connections by forming agraphical picture of said functional cores and interconnections; (b)using a schematic entry tool to create a software model of saidfunctional cores and interconnections; (c) describing a selectedmultiple-level hierarchy of the cores in graphical form and modellingthe selected hierarchy in software; and (d) for each level in theselected multiple-level hierarchy, creating a hardware descriptionlanguage file which declares the signals and relevant moduleinstantiations.
 11. A method according to claim 10 wherein said softwaremodel includes instances of modules and ports that represent input andoutput signals for each module.
 12. A method according to claim 10wherein the selected hierarchy is a system test hierarchy.
 13. A methodaccording to claim 10 wherein the selected hierarchy is based onphysical grouping of cores.
 14. A method according to claim 10 whereinthe selected hierarchy is based on clock domains.
 15. A method accordingto claim 10 wherein the selected hierarchy is based on a grouping forsubsystem simulators.
 16. A method according to claim 10 wherein theselected hierarchy is based on the requirements of an automaticplacement tool.